Remarks 

Claims 1-7 are currently pending in the present Application. Claim 3 is amended to 
correct a minor informality. The claims are not amended otherwise and the Remarks below 
simply put the application in condition for allowance. Therefore, a new search is not required 
and the Applicants respectfully submit that this Response should be entered. See MPEP 714.13. 

The Applicants acknowledge the rejection of Claims 1-7 under 35 U.S.C. § 112, first 
paragraph as failing to comply with the written description requirement. In particular, the Action 
provides that the "data account" recited in Claims 1-7 is not supported by the Specification. 
(The Action also provides that "executing" is not sufficiently described but then later states that 
executing is supported.) Applicants respectfully request reconsideration and withdrawal of this 
rejection in light of the following. 

The subject matter of a claim does not need to be described literally. In other words, the 
specific claim terms do not need to be used in the Specification for the claim's subject matter to 
be adequately supported and for the disclosure to satisfy the description requirement. MPEP 
2163.02. The written description adequately supports the claims if the written description 
"reasonably conveys to the artisan that the inventor had possession at that time of the later 
claimed subject matter." Ralston Purina Co. v. Far-Mar-Co., Inc., 772 F.2d 1570, 1575 (Fed. 
Cir. 1985) (quoting In re Kaslow, 707 F.2d 1366, 1375 (Fed. Cir. 1983)). 

The Specification, as originally filed, discloses a Stored Value Lock Box (SVLB). See 
e.g., paragraph [0012]. The Applicants respectfully submit that from the written description, one 
skilled in the art would readily understand that the SVLB is a "data account." As described in 
more detail below, the Specification describes the SVLB as providing only data as a link or 
acting as a "gate keeper" between a merchant and the consumer's credit card account. See e.g., 
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paragraph [0013] ("the provider [of the SVLB] verifies the SVLB for the credit amount and then 
authorizes and approves the transaction [between the merchant and customer]. The system then 
contacts the credit card issuing bank, directs funds to the appropriate SVLB and transfers the 
funds ... to the merchant.") One of skill in the art would easily be able to differentiate this type 
of an account, which stores only data, from a "funded" financial account, such as that described 
in Cheong, which stores funds and from which payment for merchandise is made directly. 

In particular, the Specification describes that the SVLB stores only data for providing the 
vehicle for payment from the consumer's credit card to the merchant and for acting as a "gate 
keeper" between the two. See paragraph [0013], supra. As described, the SVLB may store data, 
such as, a customer's name, address, credit card number and a limit of an amount of money that 
may be charged to the consumer's credit card from a purchase. See e.g., paragraph [0015], 
[0018], and [0046] - ("[o]ther than electronic authorization from the consumer, data can be 
entered [to the SVLB] by the system operations personnel . . ."). 

In operation, a consumer selects an item for purchase on-line. See paragraph [0016]. At 
"check out," she enters her SVLB "account number" instead of her credit card number. Id. 
("[w]hen the purchase selection is made, the consumer preferably enters the SVLB number in 
place of the credit card number"). Once the correct SVLB account number is entered, the 
merchant contacts the SVLB account provider. See id. ("the merchant . . . then electronically 
routes the SVLB and access code supplied by the consumer along with the purchase amount"). 
The account provider reviews the data stored in the SVLB to determine, for example, whether 
the amount of the merchant's item is within the stored maximum purchase value, whether the 
consumer's credit card is still valid, whether the name and address match, etc. See paragraph 
[0016] ("the SVLB number is then verified for the authorized credit amount and authenticity of 
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the access code"); If the data stored in the SVLB is in line with the purchase, the SVLB 

provider contacts the customer's credit card bank with information to authorize the merchant to 

charge the consumer's credit card. See paragraph [0016] ("the provider then . . . routes the 

dollar amount of the transaction to the consumer's credit card issuer, and has the amount wired 

to the provider. The provider then transfers the 'funds' ... to the merchant.") In particular, 

paragraph [0047] provides: 

"The application software [of the SVLB] . . . commands the server to transfer the 
transaction information to the credit card bank via the RPN and through the 
secured gateway. Following receipt of the credit card bank's transfer of funds, the 
application software again performs discount fee calculations, and commands the 
server to transfer the remainder of the funds to the merchant server." 

Upon completion of the transaction, the credit card bank then bills the consumer directly 

for the transaction as part of the consumer's normal billing cycle. See e.g., paragraph [0013] 

("the credit card bank . . . then bills the consumer in the normal manner on their respective credit 

card accounts"). It is important to note that funds are never transferred or linked to the SVLB 

account. There is no charge to the SVLB account and payment is not provided from the SVLB 

account. Instead, as described above, only data and other account information useful in 

facilitating transactions is stored in the SVLB account. Funds are stored with the consumer's 

credit card bank until a purchase is executed. Then, funds are provided directly from the 

consumer's credit card bank. 

In addition, throughout the Specification, terms such as "fill," "replenish," "hold" and 
"funds" are in quotes, denoting that they are not being used in their traditional sense. Indeed, 
one skilled in the art would understand that the SVLB is not literally being filled or replenished 
with funds, but is instead being updated with data relating to a customer's actual financial 
account. 
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Finally, the Specification provides that "The SafetyCash System is not in competition 
with any current financial service product, but rather [is] an alternative vehicle for loan or credit 
generation." See paragraph [0021]. In other words, the Safety Cash System does not provide a 
funded account. As a result, one of skill in the art would understand that the SVLB does not 
hold funds, any sort of currency, money, credit, etc. and payment cannot be effectuated directly 
from the SVLB. Further, based on the data stored in the SVLB and its function as an 
intermediary between a funded source and a merchant, one of skill in the art would understand 
that the SVLB is a data account. 

The Applicants acknowledge the rejection of Claims 1, 2, and 4-6 under 35 U.S.C. §103 
as being unpatentable over US 7,006,993 to Cheong et al. ("Cheong") in view of US 
2005/0192896 ("Hutchinson"). The Applicants also acknowledge the rejection of Claims 3 and 7 
as unpatentable over Cheong in view of Hutchinson, further in view of US 2005/0035193 
("Gustin"). Reconsideration and withdrawal of the obviousness rejections is respectfully 
requested in light of the following. 

Even assuming arguendo that one skilled in the art would combine Cheong with any of 
the aforementioned other references, the combination does not disclose every element of 
independent Claim 1 . In particular, Applicants respectfully submit that none of the references, 
and in particular Cheong, disclose a data account. 

As discussed above, the SVLB is strictly a data account that holds customer data and 
related information. The SVLB does not store any kind of funds, is not linked to any financial 
institution, and payment for merchandise may not be provided directly by the SVLB. 
Conversely, Cheong discloses a funded financial account that may be used to pay for purchased 
items directly, similar to a typical credit card account. In particular, in Cheong' s system, a 
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consumer funds a surrogate system credit card (the so-called funded account). See Abstract ("the 
account can be funded using numerous fund sources" and "[t]he [surrogate system] credit card, 
once loaded with funds from the user's corresponding funded account, is used to complete the 
purchase transaction.") After the consumer executes a transaction, upon "check out," 
merchandise is directly paid for by funds previously deposited in the surrogate system credit 
card account. See col. 17, Ins. 50-54 ("Funds are loaded from the user's account to the surrogate 
system credit card. The purchase transaction is executed using the surrogate system credit 
card.") Thus, in Cheong's system, the consumer may engage in e-commerce purchase 
transactions only after the consumer's account is funded with actual funds. As the consumer 
makes such purchases, the consumer's actual available funds are reduced accordingly. Once the 
funds are depleted, the consumer must replenish the surrogate account with actual funds before 
executing any further transactions. 

The data account of Claim 1, in sharp contrast, stores only data for facilitating purchases 
made from the consumer's actual credit card. Data stored in this data account is used for 
authentication, and to request from the consumer's credit card account that payment be made to a 
merchant. No funds are ever stored or withdrawn from the data account of Claim 1 . Therefore, 
since Cheong fails to disclose a data account, and instead requires a fully funded, financial 
account, the Applicants respectfully submit that Claims 1-7 are fully patentable over Cheong. 

The Applicants also respectfully submit that none of the other cited references disclose a 
data account. Hutchinson, for example, discloses that consumers consummate purchases using a 
virtual payment card, which operates similarly to Cheong's surrogate system credit card. See 
Abstract. In other words, Hutchinson's account is a funded financial account similar to 
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Cheong's. Gustin discloses an automated document cashing system that does not provide a data 
account or other intermediary account between a merchant and consumer. 

Based on the foregoing, the Applicants respectfully submit that any combination of the 
aforementioned references fails to disclose each and every element of Claim 1. Therefore, Claim 
1, and Claims 2-7 which recite similar features, are all fully patentable over any combination of 
Cheong, Hutchinson, and Gustin. 

In view of the foregoing, Applicants respectfully submit that the entire application is now 
in condition for allowance, which notice is earnestly solicited. 



Respectfully submitted, 
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